In wireless network, resource-restricted devices, including energy-restricted devices such as energy-harvesting devices, can be used. Such devices are heavily restricted in the available amount of energy, which limits their offered functionality and influences the network operation, commissioning and maintenance.
One example of such technology is the evolving ZigBee Green Power (ZGP) standard. A ZGP device (ZGPD) is a resource-restricted device which may be powered by energy harvesting and which may not have a battery or which may only have a small storage capacity and can thus transmit and/or receive only at unscheduled opportunities. For example, a ZGPD can be a battery-less switch that can only transmit for a short time once it is actuated by a user and has no reception capability. Another example of a ZGPD can be a battery-less switch that can receive for a short time once it is actuated by a user and has transmitted its signal. Yet another example of a ZGPD is a periodically-reporting sensor, harvesting energy from its environment, e.g., by means of a photovoltaic cell, with or without reception capabilities. If an energy-restricted device is out of range of the device it is configured to control (the device to be controlled referred to as a “sink” or “destination device”), an intermediate device (referred to as a “proxy”) is used for forwarding information to the sink. The wireless links between the proxy and the restricted device may appear and disappear during network lifetime, e.g., due to changes in propagation conditions or in relative location of devices, and/or due to devices being added and removed. For system security and performance reasons, the proxies may only forward for restricted devices they have a table entry (i.e. proxy table entry) for, e.g., to be able to perform freshness and/or security check (authentication, decryption). For communication reliability, more than one proxy may be used for forwarding information on behalf of a restricted device.
There are various ways to establish/extend such a proxy table entry, automatically or upon request—e.g. of a user or a maintenance and/or configuration entity. However, the approaches for entry removal currently available in the ZGP specification require user involvement, via commissioning tool usage and/or manual interaction with the restricted device and/or the controlled device (each of which may be installed up in the ceiling), which is cumbersome for large-scale network, such as building automation networks; and may require repeated removal actions if combined with the automatic proxy table creation as available in the ZGP specification today.
Due to the scale of the network and the automatic proxy table creation, there is a need for automatic proxy table management. According to the ZGP specification, it is up to the implemented proxy to choose some management heuristics, i.e., to choose heuristics that pick an entry to delete from a (full) proxy table, e.g. if a new entry must be added; the only recommended method for automatically removing proxy table entries points to these entries with the InRange flag of the Options field set to “0b0”, optionally in combination with ZGPDfixed sub-field of the Options field also set to “0b0” (cf. ZGP best practices for ZBA, ZigBee document 11-0196r01, section 5.4.2.1, page 24, line 22-24); or to entries with the EntryActive flag of the Options field set to “0b0”, which can be moved to the zgppBlockedZGPDID list (ZigBee document 09-5499r23, section 3.5.2.2.1, line 21-23). Other possible heuristics are left out of scope of ZGP specification; they may refer to experience-based techniques for problem solving, learning, and discovery. Where an exhaustive search is impractical, heuristics are used to speed up the process of finding a satisfactory solution. Examples of such heuritics include using a rule of thumb, an educated guess, an intuitive judgment, or common sense. The most fundamental heuristic is trial and error. There can be some level of freedom for proxy implementers, because though bad heuristic reduces network efficiency and reliability, a bad heuristic cannot lead to long-lasting failure of the network. In the current ZGP specification, there is no performance penalty for proxies having a very full proxy tables, so that aggressive cleaning to shrink a proxy table much below the size of the available memory in a proxy has no beneficial effect.
The current ZGP specification offers some other mechanisms for proxy table maintenance, esp. proxy table entry creation. For example, in the commissioning process (likely with user involvement), the sink or a commissioning tool sends a control announcement (e.g., ZGP Pairing command with AddSink flag set to “0b1”), informing the proxy(s) about the new control relationship created, including an identifier of the restricted device and the corresponding sink(s). This control announcement can be sent by (range-limited) broadcast, with the proxy(s) optionally adding the table only if they are in the range of the limited device, especially if the device indicates fixed location. During operation, proxy table entry creation can be achieved at the proxy by receiving an unsolicited control announcement, or a communication from an unknown restricted device and seeing other proxy(s) forwarding it, or a communication from an unknown restricted device and making a query for control relationships (e.g., ZGP Pairing Search command or broadcast ZGP Notification command). Proxy table entries can be removed after reception of the Decommissioning GPDF (Green Power Device Frame) from the restricted node in commissioning mode (specially triggered on the restricted node), or after reception of a control removal command (e.g., ZGP Pairing with AddSink flag set to “0b0” or with RemoveZGPD flag set to “0b1”), specially triggered on the sink/commissioning tool.
Other automatic proxy table operations mentioned in the ZGP specification are clearing of the first-to-forward flag and/or removing any packets queued for forwarding upon receipt of a forwarded communication by another proxy or a confirmation packet from the sink (cf. ZGP specification, ZigBee document 09-5499-23, section A.3.5.2.1, page 124, line 9-39), or clearing of the first-to-forward flag and removing any packets queued for delivery to the restricted device upon receipt of a request to send to the restricted device with another proxy being nominated (cf. ZGP specification, ZigBee document 09-5499-23, section A.3.5.2.1, page 122, line 43-page 123, line 5).
The above-mentioned approaches allow to determine the status of the proxy table entry. However, due to the unforeseeable schedule of transmissions by the restricted device (which may be dependent on the amount of available energy and/or user interaction) and the unreliable nature of the wireless transmissions, especially from restricted devices which potentially do not use acknowledgements (ACKs) and channel access procedures (such as Carrier sense multiple access with collision avoidance (CSMA/CA)), simple approaches for automatic proxy table removal based on aging (e.g. remove entries that will expire soonest, remove entries that were created earliest, remove entries that were used least) is not appropriate for the restricted devices.
Although several solutions for proxy devices to autonomously take their decisions to create, keep, update or remove a proxy table entry are known, they do not guarantee optimal system performance with efficient allocation of proxies (at required redundancy level) per restricted device.